A multiplayer first-person spellcaster in which players work in teams to obliterate their enemies. The game was an ambitious university group project with four members as a part of the group. The allocated timeframe to complete the project was thirteen weeks, with sprints counting every second week.
I was responsible for :
One of the primary ones for game development is properly defining core mechanics and developing the mechanics that prioritise those that suit the intended player experience. We failed to express our core mechanics adequately due to the bloated list of features we wanted to implement into our scope within the allotted time. In hindsight, in the initial three sprints, we should have focused on; movements controlled by the keyboard, shooting, player health, player death, rounds, assigning teams and networking. Rather than focusing on movement controlled by key presses, destructible walls, climbing, vaulting, and networking. If we had done this, we would have prioritised the mechanics that would serve the intended player experience of a competitive team shooter and let us have a much stronger foundation to add things like destructible walls, the planting game mode and ghosts.
In addition, designing the most technically tricky game components should not have taken precedence over the less complicated but vital features that create the intended player experience. For example, mechanics such as; players being able to shoot each other, lose health, and die, were more critical to implement than climbing and destructible walls, as these features are the fundamental aspects for a player versus player experience. Therefore, prioritising the essential mechanics and correctly identifying them is a skill that I can utilise in future projects to ensure that the game has a strong foundation and can deliver the desired player experience.
Another lesson learned throughout the project is the importance and difficulty of organising playtesting. The value of playtesting was never in question; however, we did underestimate the difficulty of obtaining playtesters. The main issue was that we required four players to play simultaneously, and we had to view their perspectives as they played. Initially, we reached out to those within our friend groups interested in playing FPS games to playtest, but we had few who could play within the timeframe before the end of a sprint and even fewer who could play simultaneously. The lesson here being we should have invited as many people in our friend groups as possible, and we should have asked earlier on in the sprint to set a date with them that works.
Another lesson is that we should have had playable builds to playtest before the weekend of the second week in a sprint, as we found that our playtesters were generally only able to play on a Saturday. We failed to do this for sprint four due to crunch, which meant we did not realise that we forgot to make shooting enjoyable to players until it was almost too late. In future endeavours, it would be best to playtest at least once every sprint and to reach out to all our contacts to ensure that we can have more people to test the game potentially.
In terms of communication, a lesson learned was to be firm about holding team-wide meetings and setting deadlines before the sprint end. We grew lax in our duty to hold team-wide meetings, instead preferring meetings where only half the group was present or simply communicating over Discord in the later stages of the project. We relied on text updates to explain the work we were completing and rarely showed or discussed how we were implementing features instead of the project’s start. While we still had meetings at the end of sprints, they were typically about the workload for the next sprint and what features should be implemented into the game. The problem is that it felt like we were a collection of individuals working on different parts without a clue how they connected, rather than a team working together to create an enjoyable experience with a shared and clearly defined vision. There was also no discussion about ensuring a playable build was deployed and tested before the end of the sprint. Some features were only completed on the last day of the sprint as there were no in-group deadlines set, which caused delays to the playtests. In the future, in-group deadlines will be pivotal to ensuring that we have a playable build that is playtested before the end of a sprint. Another consideration is to hold more meaningful and common meetings, particularly in the second week of a sprint, to ensure the group are all on the same page and understand how the features they are implementing can impact the game experience.